Ein gemeinsamer Kontext für KI-Programmieragenten ist besser als bessere Tools

Der erste Reflex beim Einsatz von KI-Coding-Agenten ist, den Agenten zu optimieren. Man vergleicht Modelle, optimiert Prompts, diskutiert darüber, welcher Editor die bessere Autovervollständigung bietet, und betrachtet den Agenten als das, was bestimmt, wie schnell das Team vorankommt. Dann steigen die Commits, aber das Produkt kommt nicht voran.

Das Team, das Upsun Dispatch™ entwickelt hat, ist einen anderen Weg gegangen, und das Ergebnis ist nachahmenswert. Sie haben keinen besseren Agenten gefunden. Stattdessen haben sie jeder Person und jedem Agenten im Team denselben Kontext zur Verfügung gestellt: ein Repository, einen gemeinsamen Dokumentensatz, ein Glossar, an das sich alle halten. Die Geschwindigkeit ergab sich daraus.

Der Agent war nie der Engpass

Patrick Dawkins, Principal Engineer bei Upsun, beschreibt die Herausforderung in der neuesten Folge von „Product Highlights“ ganz klar: Das Team beschloss, in kurzer Zeit etwas Ehrgeiziges zu entwickeln, und musste dann herausfinden, wie es dieses Tempo tatsächlich aufrechterhalten konnte.

Der Teil mit den Tools war der einfache Teil. „Wir setzen im Team stark auf KI“, sagt Patrick. „Vieles davon läuft ganz natürlich ab, also nutzt jeder seine Programmier-Agenten. Unser Review-Agent läuft ebenfalls.“ Niemand musste dazu überredet werden.

Aber bei der individuellen Umsetzung stocken die Fortschritte oft. Upsun hat bereits darüber geschrieben: Das Problem war nie das Tippen. Ein Entwickler, der auf seinem eigenen Rechner mit seinem eigenen Framework und seinem eigenen gesammelten Kontext schnell vorankommt, liefert Ergebnisse, die der Rest des Teams erst noch verstehen, prüfen und integrieren muss. Multipliziere das mit mehreren parallel laufenden Agenten, und die Überprüfungsqueue verschlingt jede Stunde, die die Agenten eingespart haben.

Ein Repository, ein Dokumentensatz, ein Vokabular

Was sich bei Upsun geändert hat, war die Basis, auf der die Agenten laufen – nicht die Agenten selbst.

Alle arbeiten im selben Monorepo. Die Dokumentation wird im gesamten Team geteilt – und zwar nicht nur die technische Dokumentation. „Ich glaube, das ist gemeinsam aus den Bereichen Marketing, Produkt und Entwicklung entstanden“, sagt Patrick. Die Dokumente umfassen sowohl die Arbeitsplanung als auch die Planung der langfristigen Vision, sodass die Begründung hinter einer Entscheidung direkt neben dem Code steht, der sie umsetzt.

Das hat einen zweiten Effekt, der leicht übersehen wird. Jedes Dokument, das für einen Menschen geschrieben wurde, ist auch ein Dokument, das ein Agent lesen kann. Wie Patrick es ausdrückt: „So wie das gesamte Team Zugriff auf dieselben Inhalte und dasselbe Vokabular hat, haben auch alle Agenten Zugriff auf diese Dokumente.“

Der Zugriff ist bewusst weit gefasst. Sowohl das Team als auch die Agenten können auf das Backend, das Frontend, den Infrastruktur-Code und die Terraform-Konfigurationen zugreifen, die die Infrastruktur aufbauen. Ein Agent, der gebeten wird, einen Dienst zu ändern, muss nicht raten, wie dieser Dienst bereitgestellt wird.

Was passiert, wenn der nicht-technische Kontext nicht mehr verborgen bleibt

Das deutlichste Beispiel kam von außerhalb der Technik. Greg Qualls, Senior Director für Produktmarketing und Content bei Upsun, ist seit fast fünf Jahren im Unternehmen und beschreibt die Arbeit im Produktmarketing als etwas, das früher außerhalb der Sichtweite des Quellcodes stattfand.

Die Einbindung in das gemeinsame Repo veränderte, wer darauf zugreifen konnte. Es war nicht mehr sein Kontext oder gar der Kontext seiner Agenten. Wie Greg es ausdrückt: „Es steht dir und deinen KI-Agenten zur Verfügung.“

Der praktische Unterschied zeigt sich in den kleinen Fragen. Die Art von Fragen, die früher auf ein Meeting warten mussten oder darauf, dass die richtige Person online war, finden nun eine Antwort im Repo, die entweder ein Mensch oder ein Agent finden und umsetzen kann. Multipliziere diese kleinen, ungehinderten Entscheidungen mit einem Team, das zügig arbeitet, und es ist plötzlich keine Kleinigkeit mehr.

Genau diese Überzeugung prägt Upsun Dispatch als Produkt: Das gesamte Team bringt etwas auf den Markt, nicht nur die Entwickler. Produkt, Design und Sicherheit sind direkt in den Workflow eingebunden, verfolgen Durchläufe und genehmigen Meilensteine, ohne zu programmieren.

Ein Glossar ist heute Infrastruktur

Die übertragbarste Idee in dieser Diskussion ist gleichzeitig die unspektakulärste. Patrick legt großen Wert auf die Namensgebung, und das aus einem ganz bestimmten Grund.

Wenn man etwas Neues aufbaut, muss man Dinge benennen, und die in Frage kommenden Bezeichnungen liegen frustrierend nah beieinander. Aktivität. Aufgabe. Job. Ausführung. Schlimmer noch: Sie lassen sich nicht immer zu einem Begriff zusammenfassen, weil ein Tool im Stack möglicherweise bereits einen davon beansprucht. Temporal bringt zum Beispiel sein eigenes Vokabular mit, und das Team muss die Bedeutungen über alle darüber- und darunterliegenden Ebenen hinweg aufeinander abstimmen.

Wenn man das falsch macht, verdoppeln sich die Kosten. „Sonst gibt es für die Leute und für unsere Agenten für immer Verwirrung“, sagt Patrick. „Deshalb bin ich bei unserem Glossar ziemlich pedantisch.“

Begriffsverschiebungen waren schon immer kostspielig. Wenn eine Person in einem Design-Gespräch einen Begriff nur leicht falsch verwendet, kann das eine Woche Arbeit in eine Richtung lenken, die niemand beabsichtigt hat – und der Fehler kommt meist erst spät ans Licht. Agenten verschlimmern das auf besondere Weise: Sie sind sprachgewandt, selbstbewusst und völlig abhängig von den Wörtern, die ihnen vorliegen. Ein Agent, dem zwei Definitionen von „Aufgabe“ vorgelegt werden, hält normalerweise nicht inne, um zu fragen, welche du gemeint hast. Er wählt eine aus und programmiert.

So ist das Glossar nicht mehr nur eine Frage der Dokumentationshygiene, sondern wird Teil dessen, wie sich das System verhält. Die Pedanterie lohnt sich.

Dann bring die Pipeline aus dem Weg

Ein gemeinsamer Kontext erhöht die Arbeitsmenge, die das Team in Angriff nehmen kann. Er erhöht aber auch die Arbeitsmenge, die zur Überprüfung gelangt – und genau dort entsteht als Nächstes der Druck.

Patricks Antwort ist unspektakulär und richtig: „Ich habe versucht, unsere gesamte CI sehr effizient zu gestalten, einfach um sie aus dem Weg zu räumen und uns dabei zu helfen, PRs ständig zu prüfen und zusammenzuführen.“ Keine schnellere Überprüfung durch Abstriche. Schnellere Überprüfung, weil die Pipeline kein Grund mehr zum Warten ist.

Diese Reihenfolge ist wichtig für jeden, der das versucht. Ein gemeinsamer Kontext ohne schnelle Pipeline verlagert die queue lediglich.

Wo Upsun Dispatch ins Spiel kommt

Für nichts von alledem braucht man ein Produkt. Ein Team kann ab Montag seine Doku ins Repo stellen, ein Glossar erstellen und seine CI straffen. Was man von Hand nur schwer hinbekommt, ist alles, was danach kommt: Agenten außerhalb eines Laptops laufen zu lassen, einen Workflow zweimal auf dieselbe Weise ausführen zu lassen, festzuhalten, wer was genehmigt hat, und zu wissen, was ein Durchlauf gekostet hat.

Genau diese Lücke soll Upsun Dispatch schließen. Die Grundidee ist, dass der Workflow die Basis ist, nicht der Agent. Agenten laufen in isolierten Sandboxes statt auf privaten Rechnern, jeder Workflow ist eine definierte Abfolge von Agenten- und menschlichen Schritten, menschliche Prüfpunkte erfordern eine echte Entscheidung statt einer Benachrichtigung, und jeder Durchlauf wird mit den zugehörigen Kosten protokolliert. In Verbindung mit den Upsun-cloud-Preview-Umgebungen erhält jede Änderung zudem eine Byte-für-Byte-Kopie der Produktivumgebung, an der sie getestet werden kann.

Der Grund, warum die interne Geschichte relevant ist, liegt darin, dass das Produkt dieselbe Überzeugung verkörpert. Ein gemeinsamer Kontext, ein vereinbartes Vokabular und ein Prozess, den das gesamte Team einsehen kann – das ist es, was aus fähigen Modellen ein Team macht, das Ergebnisse liefert. Der Agent ist der einfache Teil.

Upsun Dispatch steht derzeit einer Gruppe von Gründungs-Designpartnern offen, die sich an Entwicklerteams mit 50 bis 500 Mitarbeitern richtet; die vollständige öffentliche Einführung ist für September 2026 geplant. Designpartner arbeiten direkt mit dem Entwicklerteam zusammen und beeinflussen, welche Workflows zuerst veröffentlicht werden. 

Du kannst dich auf die Warteliste setzen lassen oder dir das vollständige Gespräch mit Patrick hier ansehen.